ci: catch release-bump dependency rebinds on the PR that causes them - #4223
Merged
Conversation
packethog
approved these changes
Aug 21, 2026
nikw9944
force-pushed
the
nikw9944/doublezero-4220
branch
from
August 21, 2026 20:58
bfa8b10 to
451150f
Compare
nikw9944
enabled auto-merge (squash)
August 21, 2026 21:01
ben-dz
approved these changes
Aug 24, 2026
ben-dz
left a comment
Contributor
There was a problem hiding this comment.
The guard works — verified it fails on 95336a36 naming the reqwest/tokio-util rebind, passes on HEAD, and passes on an already-bumped release tree. The findings are all about the failure path: the Fix: hint attributes any Cargo.lock failure to a rebind, but an uncommitted lock trips the same guard and gets sent to pin a requirement that does not exist. Two smaller items on the second hint's stated mechanism and a missing timeout-minutes.
Docs & comments (non-blocking)
.github/workflows/rust.yml:96— An upstream publish cannot trip this guard:cargo update --workspacekeeps already-locked versions rather than chasing the index. Three runs of this step (pre-#421995336a36, the v0.37.0 bump commit, and HEAD) each left ~261-263 dependencies "behind latest" while touching only the 16 member entries; a rebind needs a tree change (loose requirement plus a second locked version, as in #4213) or a yank. "Check this job on main" is still the right action — attribute it to a PR merged since your base and drop the publish clause.
The release's version bump runs cargo update --workspace, which re-resolves every workspace member's dependency edges and can silently rebind them onto a different locked minor. bump-version.sh already fails on that, but only ran at release time, so the rebind that broke the v0.37.0 testnet release sat dormant for a week after the PR that made it possible. Run the same script against a throwaway next-minor version in PR CI and discard the result, so the failure lands on the PR that causes it. Refs #4220
Say plainly that the job is advisory until its context is added to the main ruleset, and that a rebind can also arrive from the live crates.io index rather than from the PR under test. Move the remedy into plain log lines so the error annotation stays short enough to read in the Annotations panel. Refs #4220
An uncommitted Cargo.lock after a Cargo.toml dependency edit trips the same guard as a rebind, and the old hint sent that case to pin a requirement that does not exist. Drop the upstream-publish clause too: cargo update --workspace keeps already-locked third-party versions, so a publish alone cannot rebind. Cap the job at 10 minutes so a hung run cannot sit on GitHub's six-hour default once the context is required. Refs #4220
nikw9944
force-pushed
the
nikw9944/doublezero-4220
branch
from
August 24, 2026 14:11
451150f to
947f476
Compare
Contributor
Author
|
Rebased onto
Nothing skipped. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary of Changes
release-bump-dry-runjob runs the realscripts/release/bump-version.shagainst a throwaway next-minor version on every PR and push tomain, then discards the result.cargo update --workspacecan silently rebind workspace members onto a different locked minor.bump-version.shalready fails on that, but only ran at release time, so the rebind that broke v0.37.0 sat dormant for a week after ip-verifier: add the IP ownership verification service #4213 (pinned in deps: pin reqwest and tokio-util to their locked 0.x minors #4219). This puts the failure on the PR that causes it.Two things the diff cannot cover:
rust.ymlconfers nothing (rust-validator-testandrust-cli-staticare in this workflow and not required either). Once it is green onmain, append{"context":"release-bump-dry-run"}torequired_status_checks. Noted in the docs paragraph and CHANGELOG entry.maintoo. This is the release-day flakiness moved somewhere cheap to fix; the remedy is always to pin the requirement, which the job's failure output says.The bare-
"0"lint (item 2 in #4220) is out: 27 such requirements remain and would all need pinning first, and this guard catches the consequence however the requirement is spelled.Testing Verification
95336a36(ip-verifier: add the IP ownership verification service #4213 as merged, pre-deps: pin reqwest and tokio-util to their locked 0.x minors #4219): fails, naming the addedreqwest 0.12.28/tokio-util 0.6.10lines and the newhyper-tls/native-tls/tokio-native-tlspackages — the same diagnosis the v0.37.0 release produced a week later. Passes on the current tree.Cargo.tomlalready bumped, CHANGELOG already promoted): next-minor keepsPREV != NEW, the second bump adds only member version lines, job passes. No special-casing needed.